900612 ESP -- SURF Center : Requirements (and Gathering) Documentation
This page last changed on Dec 02, 2014 by kgomes.

In order to gather the requirements for the Graphical User Interface, the GUI team met with the ESP science and engineering members to try to determine what the GUI needs to do. We also poured over relevant documentation to try to extract as much knowledge as we could about the system before defining the requirements (see below). The following requirements were gathered as part of that process.

Requirements

Number Requirement Goal
  User can define missions by specifying phases Planning
  User can specify and adjust phase start times Planning
  User can also specify a time to wait between events instead of a specific start time Planning
  User can set mission start and end times that are not associated with a phase/protocol Planning
  User can specify comments associated with missions that are printed at the top of the mission script Planning
  After planning, application should generate mission script, puck loads, and reagent volumes Planning
  User can add comments to a phase that will be generated in the script Planning
  Users can add/delete/edit protocol runs and phases Planning
  Users can load missions from existing ruby scripts Planning
  Users can specify thresholding events in plans (example) Planning
  Users can copy existing phase and protocol to crate duplicate Planning
  Users can add/delete/edit consumables Planning
  Users can schedule Kills (end purges) or disable kills Planning
  Users can define generic events and what script will actually be added to the master script (if needed) Planning
  Mission plan generation will include a puck loading list Planning
  User can associate external files with events (excel spreadsheet, documents, etc.) Planning, Data Management
  Tide and phase information will be available Planning, Data Management
  Application will list sample volumes with protocol run Planning, Data Management
  User can add non-phase/protocol events (user defined) to the calendar anywhere Data Management
  User can view images associated with phases Data Management
  User can browse the .GAL file along with image and filter paper information Data Management
  User can browse image, click on intensity and application applies .GAL/Map with standard curves to give density Data Management
  User can browse the low-res images that come over the telemetry until full size image is offloaded after recovery Data Management
  When users selects a protocol run/phase, the contextual data (CTD/ISUS) should be shown Data Management
  Application should allow for details of flushes to be seen/accounted for Data Management
  The application should archive (and make available) the environment variables for each deployment and make available to user. These variables are:
  1. ESPhome: Is the directory on the linux host which is the top level (root) of the directory of ESP source code tree
  2. ESPname: is the name of the ESP machine
  3. ESPmode: is the operating mode in which to run the ESP software
  4. ESPlog: is the root directory on the linux host under which all data files are written.
  5. ESPpath: is a list of directories on the linux host to search for mission scripts.
  6. ESPconfigPath: is a list of directories to search for configuration files. The path will include the ESPtype which is either shallow, mfb, 1km, or 4km.
  7. RUBYLIB: is a list of directories to search for the "required" Ruby libraries and scripts
 Data Management
  Users should be able to download instrument logs and images and the GUI will parse out the following events:
  • Track deployments of contextual sensors (sub-deployments of ESP)
  • Collection of contextual sensor data (with capability to view/work with data)
  • Phase Start Time
  • Start Time of Initial Purge (what version if there is one)
  • End Time of Initial Purge (what version if there is one)
  • Start Time of SH1 (Protocol for sample collection/homogenization)
  • Start Time of Actual Sample Collection for SH1
  • End Time of Sample Collection for SH1
  • Volume of Sample Collected
  • End Time of SH1
  • Start Time of SH2 Protocol (Generally preceeds end of SH1)
  • Start Time of WCR (Generally preceeds end of SH2)
  • Start Time of Actual Sample for WCR
  • End Time of Sample Collection for WCR
  • Array Images (Generally >1 and >1 resolution/binning, exposure times)
  • End of SH2
  • End of WCR
  • Start Time of final purge (what version, if there is one)
  • End Time of final purge (what version, if there is one)
  • Phase End Time
 Data Management, State Visualization
  Application will track status of consumables:
  1. Pucks
  2. Reagents: 20 or so
  3. Waste
  4. Power
 State Visualization
  Users can visualize the current state of the instrument State Visualization
  Users can scroll back in time and visualize instrument state at the various points in time State Visualization
Document generated by Confluence on Feb 03, 2026 14:16